Cloud Monitoring の 稼働時間チェック(uptime checks) で公開サービスの死活監視を行う

はじめに

Cloud Monitoring の 稼働時間チェック(uptime checks) は、世界中の複数のロケーションから一般公開されている URL または Google Cloud リソースにリクエストを発行して、リソース応答を定期確認する機能です。

稼働時間チェックを利用して以下の公開リソースのサービス状態を死活監視できます。
- 公開URL / Hostname / IP address
- VM インスタンス
- App Engine アプリケーション
- Kubernetes サービス
- Cloud Run のリビジョン
- Amazon EC2 インスタンス
- Amazon Elastic Load Balancing

稼働時間チェックの詳細は以下を参照ください。

稼働時間チェックの料金

稼働時間チェックは毎月100万回実行の無料枠があります。無料枠を超過すると 1,000 回の実行ごとに $0.30 の費用がかかります。3つのリージョンからの稼働時間チェックを1分間隔で構成すると、1分で3回の実行としてカウントされます。

詳細の見積方法は以下を参照してください。

HTTPSによる稼働時間チェックを構成する

Compute Engine にて起動したVMインスタンス上で構成するWebサーバ(HTTPS)に対する稼働時間チェックを Cloud Console で構成し、サービス状態の死活監視を行ってみます。

ユーザへのIAMロール付与

Cloud Console 上から稼働時間チェックを構成するために、Monitoring 編集者roles/monitoring.editor が必要となります。
なお、本検証ではオーナー権限を利用しています。

稼働時間チェックの作成

[Monitoring]→[稼働時間チェック]を選択し、[稼働時間チェックを作成]をクリックします。

各項目を設定します。

「ターゲット」では監視対象やプロトコル、稼働時間チェック用のリクエストの内容を設定します。設定値を以下にて解説します。

• Protocol: HTTP / HTTPS / TCP から選択します。TCPの場合は任意のポート番号を指定します(HTTP / HTTPSの場合でもポート番号の変更は可能)。ここではHTTPSを選択します。
  
• リソースの種類: URL や Instance、Cloud Run Service などの監視対象リソースを指定します。Internal IP を指定する場合は非公開稼働時間チェック(private uptime checks)の構成が必要です。ここでは　Instance を選択します。
  
• 適用先: Single または Group を選択します。Single は特定のVMインスタンス、Group は特定の Monitoring Group を指定できます。Monitoring Group は監視対象をグループ化したもので監視設定の管理を容易にします。Monitoring Group は [Monitoring]→[グループ]から設定可能です。ここでは Single を選択します。
  
• Instance: リソースの種類を Instance とした場合に、監視対象とするインスタンスを指定します。ここではwebserverという名前のインスタンスを選択します。
  
• Path: Protocol が HTTP / HTTPS の場合にリクエスト先の URL Path を指定することができます。値を未指定とするとhttp://<監視対象>/にリクエストを送信します。ここでは未指定とします。
  
• Check Frequency: リクエストを送信する間隔を 1/5/10/15 minutes から指定します。ここでは 1 minute とします。
  
• Regions: 稼働時間チェックの送信元サーバのリージョンを最低3つ指定します。グローバルを指定するとすべてのリージョンからリクエストが送信されます。ここでは、アジア太平洋/ヨーロッパ/米国（アイオワ）を指定します。
  
• ICMP Pings: 稼働時間チェック中に 最大3回の ICMP Ping によるチェックを追加する場合に Ping の回数を設定します。稼働時間チェックに失敗すると Cloud Logging ログのhttpRequestフィールドに ICMP に関するフィールドが追加されるためトラブルシューティングに活用できます。ここでは 0 と設定します。
  
• Request Method: Protocol が HTTP / HTTPS の場合に Request Method を GET または POST から指定できます。ここでは GET とします。
  
• Host Header: Protocol が HTTP / HTTPS の場合に Virtual Host を監視する場合に設定します。ここでは未指定とします。
  
• Port: ポート番号を指定します。ここでは 443(デフォルト)とします。
  
• Custom Headers: Custom Header を追加し、必要に応じて暗号化します。暗号化するとヘッダーの値はフォームに表示されません。ここでは未指定とします。
  
• 認証: Protocol が HTTP / HTTPS の場合に Authorization ヘッダーを指定する際に設定します。ここでは未指定とします。
  

「レスポンスの検証」では期待するレスポンスのタイムアウト期間やレスポンスの内容について設定します。設定値を以下にて解説します。

• Response Timeout: 稼働時間チェックのタイムアウト期間を設定します。この期間内にレスポンスを受領しなかった場合、稼働時間チェックが失敗となります。ここでは 10 seconds とします。
  
• コンテンツ マッチ: レスポンスデータをチェックする際に設定します。ここでは無効とします。
  
• Log check failures: 有効にすると稼働時間チェック失敗時に Cloud Logging ログに保存されます。
  
• 有効な HTTP レスポンス コード: 稼働時間チェックで有効と判断するレスポンスコードを設定します。ここではデフォルトの Response Code Classes と 2XX を設定します。
  

「アラートと通知」ではアラートと通知に関する設定を行います。設定値を以下にて解説します。

• アラートを作成する: 稼働時間チェックが失敗した場合に通知を受け取るには、アラートポリシーを作成する必要があります。ここでは有効にします。
  
• Name: アラートポリシーの名前を指定します。ここではUptime failureとします。
  
• Duration: 稼働時間チェックの失敗の通知を送信するまでの時間を選択します。ここでは 1 minute とします。
  
• 通知チャンネル: 通知先となる通知チャンネルを設定します。通知チャンネルは以下のように[MANAGE NOTIFICATION CHANNELS]で設定することが可能です。ここでは Email の通知先を指定します。
  

最後に稼働時間チェック自体の名前、ユーザーラベル(容易な管理のためにKey-Value形式でラベル指定ができる)を設定します。作成を完了する前に以下のように[TEST]をクリックすることで稼働時間チェックの構成を確認することができます。

最後に[CREATE]をクリックして稼働時間チェックの作成は完了です。

稼働時間チェックのステータス確認

[Cloud Monitoring]→[稼働時間チェック]から対象の稼働時間チェックを選択することで、各リージョンからの稼働時間チェックのステータスやレイテンシが確認できます。

次に Compute Engine を停止して稼働時間チェックのステータスを確認してみます。

稼働時間チェック失敗により、メールによるアラートが送信されたことも確認できました。

注意点

稼働時間チェックは公開サービスに対してのリクエストによる監視であるため、もちろんですが非公開サービスに対しての監視はできません。非公開サービスへの監視が必要な場合は非公開稼働時間チェック(private uptime check)の構成が必要です。

また、稼働時間チェックサーバからのリクエストを許可するためにファイアウォールを構成する必要があるケースもあると思います。ファイアウォールの構成のために稼働時間チェックサーバの送信元IPアドレスが必要な場合、[Monitoring]→[稼働時間チェック]を選択し、以下赤枠のダウンロードアイコンをクリックすることでIPアドレスの一覧が取得可能です。

おわりに

本ブログでは Cloud Monitoring の稼働時間チェックの設定について説明しました。稼働時間チェックは HTTP / HTTPS によるWebアプリケーションの死活監視という観点だけでなく、VMインスタンスの起動確認の観点でも利用できる機能かと思います。また、Monitoring Group を利用することでスケールした際の設定や管理もシンプルにすることができそうです。